home *** CD-ROM | disk | FTP | other *** search
/ Software of the Month Club 2000 October / Software of the Month - Ultimate Collection Shareware 277.iso / pc / PROGRAMS / UTILITY / WINLINUX / DATA1.CAB / programs_-_usrdoc / TIN / AUTH.TXT < prev    next >
Text File  |  1999-09-17  |  13KB  |  278 lines
  1.                   Authentication to a NNTP server with tin
  2.  
  3. Tin is able to do authentication to news servers according to the "Common
  4. NNTP Extensions" (see below). There are several ways of authentication
  5. described in that text which are referred to as Original AUTHINFO, AUTHINFO
  6. GENERIC, and AUTHINFO SIMPLE. Tin supports the Original AUTHINFO and the
  7. AUTHINFO GENERIC methods. In addition to answers to authentication requests
  8. as described in the "Common NNTP Extensions", tin also provides
  9. authentication at connection startup.
  10.  
  11. Authentication is always done in the same manner: First, tin tries an
  12. AUTHINFO GENERIC authorization. If this fails, Original AUTHINFO is used.
  13. Authentication requests will be handled whenever they occur; the command
  14. that caused the request will be sent again.
  15.  
  16. For an authentication with the Original AUTHINFO method, tin needs a
  17. user-name and a password for the current news server. This information is
  18. obtained from a file .newsauth in the TIN_HOME directory. The format of the
  19. .newsauth file is as follows:
  20.  
  21. news.server1 password1 [username1]
  22. news.server2 password2 [username2]
  23. ...
  24.  
  25. The first line matching the current news server is taken. The delimiters
  26. between the fields MUST be spaces. If a password contains spaces, you have
  27. to surround the whole password by double quotes. If no user-name is given
  28. for the current news server, the user-id of the user who started tin is
  29. assumed.
  30.  
  31. Security consideration: tin does not prove if the .newsauth file could be
  32. read by others. The user is responsible for accurate permissions.
  33.  
  34. If you do not have a .newsauth file in your TIN_HOME directory, tin prompts
  35. you for a user-name and a password. This is NOT done at connection startup,
  36. because there is no way for tin to find out if an authentication at this
  37. time is needed. If you need to authenticate at the beginning of your news
  38. session, you MUST provide a .newsauth file.
  39.  
  40. The AUTHINFO GENERIC authentication was implemented by someone else and has
  41. not been tested by me since I do not know a server that supports this.
  42.  
  43. To use AUTHINFO GENERIC, set up an environment variable NNTPAUTH with the
  44. command and its parameters to invoke for authentication. The content of
  45. NNTPAUTH is also used as the authenticator in the AUTHINFO GENERIC response
  46. to the server. The environment variable NNTP_AUTH_FDS is used to store file
  47. descriptors for reading from and writing to the server, and for a temporary
  48. file ("cookie"); the three descriptors are separated by dots. The
  49. authentication command can take use of NNTP_AUTH_FDS when invoked; it should
  50. exit successful if the authentication was accepted.
  51.  
  52. If NNTPAUTH is empty or not available, tin sends an "authinfo generic any
  53. <user-id>" command to the server and expects the result as an NNTP response
  54. code.
  55.  
  56. The AUTHINFO SIMPLE authentication method is not supported by tin. If you
  57. need this, drop me a message or see the source code in auth.c. With the
  58. specification below, the implementation should not be difficult.
  59.  
  60. Dirk Nimmich (97-04-05)
  61. <nimmich@uni-muenster.de>
  62.  
  63.  ---- cut here ---- Barber: Common NNTP Extensions ----
  64. [Complete document at
  65.  <URL:http://src.doc.ic.ac.uk/computing/internet/internet-drafts/draft-barber-nntp-imp-05.txt.Z]
  66.  
  67. INTERNET-DRAFT                                               S. Barber
  68. Expires: December 1, 1996                   Academ Consulting Services
  69.                                                              July 1996
  70.                          Common NNTP Extensions
  71.                       draft-barber-nntp-imp-05.txt
  72.  
  73. Status of this Document
  74.  
  75.      This document is an Internet-Draft.  Internet-Drafts are working
  76.      documents of the Internet Engineering Task Force (IETF), its
  77.      areas, and its working groups.  Note that other groups may also
  78.      distribute working documents as Internet-Drafts.
  79.  
  80.      Internet-Drafts are draft documents valid for a maximum of six
  81.      months and may be updated, replaced, or obsoleted by other
  82.      documents at any time.  It is inappropriate to use Internet-
  83.      Drafts as reference material or to cite them other than as
  84.      ``work in progress.''
  85.  
  86. [...]
  87. 3. Other Extensions
  88.  
  89. 3.1 AUTHINFO
  90.  
  91.     AUTHINFO is used to inform a server about the identity of
  92.     a user of the server. In all cases, clients must provide
  93.     this information when requested by the server. Servers are
  94.     not required to accept authentication information that is
  95.     volunteered by the client. Clients must accommodate servers that
  96.     reject any authentication information volunteered by the client.
  97.  
  98.     There are three forms of AUTHINFO in use. The original version,
  99.     an NNTP v2 revision called AUTHINFO SIMPLE and a more recent
  100.     version which is called AUTHINFO GENERIC.
  101.  
  102. 3.1.1 Original AUTHINFO
  103.  
  104.     AUTHINFO USER username
  105.     AUTHINFO PASS password
  106.  
  107.     The original AUTHINFO is used to identify a specific entity
  108.     to the server using a simple username/password combination.
  109.     It first appeared in the UNIX reference implementation.
  110.  
  111.     When authorization is required, the server will send a 480
  112.     response requesting authorization from the client. The
  113.     client must enter AUTHINFO USER followed by the username.
  114.     Once sent, the server will cache the username and may send
  115.     a 381 response requesting the password associated with that
  116.     username. Should the server request a password using the 381
  117.     response, the client must enter AUTHINFO PASS followed by
  118.     a password and the server will then check the authentication
  119.     database to see if the username/password combination is valid.
  120.     If the combination is valid or if no password is required,
  121.     the server will return a 281 response. The client should then
  122.     retry the original command to which the server responded with
  123.     the 480 response. The command should then be processed by
  124.     the server normally. If the combination is not valid, the server
  125.     will return a 502 response.
  126.  
  127.     Clients must provide authentication when requested by the server.
  128.     It is possible that some implementations will accept authentication
  129.     information at the beginning of a session, but this was not the
  130.     original intent of the specification. If a client attempts to
  131.     reauthenticate, the server may return 482 response indicating
  132.     that the new authentication data is rejected by the server.
  133.     The 482 code will also be returned when the AUTHINFO commands
  134.     are not entered in the correct sequence (like two AUTHINFO
  135.     USERs in a row, or AUTHINFO PASS preceding AUTHINFO USER).
  136.  
  137.     All information is passed in cleartext.
  138.  
  139.     When authentication succeeds, the server will create an email
  140.     address for the client from the user name supplied in the
  141.     AUTHINFO USER command and the hostname generated by a reverse
  142.     lookup on the IP address of the client. If the reverse lookup
  143.     fails, the IP address, represented in dotted-quad format, will
  144.     be used. Once authenticated, the server shall generate a Sender:
  145.     line using the email address provided by authentication if it
  146.     does not match the client-supplied From: line. Additionally,
  147.     the server should log the  event, including the email address
  148.     This will provide a means by which subsequent statistics generation
  149.     can associate newsgroup references with unique entities - not
  150.     necessarily by name.
  151.  
  152. 3.1.1.1 Responses
  153.  
  154.         281 Authentication accepted
  155.         381 More authentication information required
  156.         480 Authentication required
  157.         482 Authentication rejected
  158.         502 No permission
  159.  
  160. 3.1.2 AUTHINFO SIMPLE
  161.  
  162.     AUTHINFO SIMPLE
  163.     user password
  164.  
  165.     This version of AUTHINFO was part of a proposed NNTP V2
  166.     specification, which was started in 1991 but never completed,
  167.     and is implemented in some servers and clients. It is a
  168.     refinement of the original AUTHINFO and provides the same
  169.     basic functionality, but the sequence of commands is much
  170.     simpler.
  171.  
  172.     When authorization is required, the server sends a 450 response
  173.     requesting authorization from the client. The client must enter
  174.     AUTHINFO SIMPLE. If the server will accept this form of
  175.     authentication, the server responds with a 350 response. The
  176.     client must then send the username followed by one or more
  177.     space characters followed by the password. If accepted, the
  178.     server returns a 250 response and the client should then
  179.     retry the original command to which the server responded
  180.     with the 450 response. The command should then be processed
  181.     by the server normally. If the combination is not valid,
  182.     the server will return a 452 response.
  183.  
  184.     Note that the response codes used here were part of the
  185.     proposed NNTP V2 specification and are violations of RFC 977.
  186.     It is recommended that this command not be implemented, but
  187.     use either or both of the other forms of AUTHINFO if such
  188.     functionality if required.
  189.  
  190. 3.1.2.1 Responses
  191.  
  192.         250 Authorization accepted
  193.         350 Continue with authorization sequence
  194.         450 Authorization required for this command
  195.         452 Authorization rejected
  196.  
  197. 3.1.3 AUTHINFO GENERIC
  198.  
  199.     AUTHINFO GENERIC authenticator arguments...
  200.  
  201.     AUTHINFO GENERIC is used to identify a specific entity to the
  202.     server using arbitrary authentication  or identification
  203.     protocols. The desired protocol is indicated by the
  204.     authenticator parameter, and any number of parameters can
  205.     be passed to the authenticator.
  206.  
  207.     When authorization is required, the server will send a 380
  208.     response requesting authorization from the client. The
  209.     client should enter AUTHINFO GENERIC followed by the
  210.     authenticator name, and the arguments if any.  The authenticator
  211.     and arguments must not contain the sequence "..".
  212.  
  213.     The server will attempt to engage the server end authenticator,
  214.     similarly, the client should engage the client end authenticator.
  215.     The server end authenticator will then initiate authentication
  216.     using the NNTP sockets (if appropriate for that authentication
  217.     protocol), using the protocol specified by the authenticator name.
  218.     These authentication protocols are not included in this document,
  219.     but are similar in structure to those referenced in RFC 1731[8]
  220.     for the IMAP-4 protocol.
  221.  
  222.     If the server returns 501, this means that the authenticator
  223.     invocation was syntactically incorrect, or that AUTHINFO
  224.     GENERIC is not supported.  The client should retry using the
  225.     AUTHINFO USER command.
  226.  
  227.     If the requested authenticator capability is not found or
  228.     there is some other unspecified server program error, the
  229.     server returns the 503 response code.
  230.  
  231.     The authenticators converse using their protocol until complete.
  232.     If the authentication succeeds, the server authenticator will
  233.     terminate with a 281, and the client can continue by reissuing
  234.     the command that prompted the 380.  If the authentication fails,
  235.     the server will respond with a 502.
  236.  
  237.     The client must provide authentication when requested by the
  238.     server.  The server may request authentication at any
  239.     time.  Servers may request authentication more than once
  240.     during a single session.
  241.  
  242.     When the server authenticator completes, it provides to the
  243.     server (by a mechanism herein undefined) the email address
  244.     of the user, and potentially what the user is allowed to
  245.     access. Once authenticated, the server shall generate a Sender:
  246.     line using the email address provided by the authenticator
  247.     if it does not match the user-supplied From: line. Additionally,
  248.     the server should log the event, including the user's
  249.     authenticated email address (if available). This will provide
  250.     a means by which subsequent statistics generation can
  251.     associate newsgroup references with unique entities - not
  252.     necessarily by name.
  253.  
  254. 3.1.3.1 Responses
  255.  
  256.         281 Authentication succeeded
  257.         380 Authentication required
  258.         501 Command not supported or Command syntax error
  259.         502 No permission
  260.         503 Program error, function not performed
  261.         nnn  authenticator-specific protocol.
  262.  
  263. [...]
  264. 5.0 Security Considerations
  265.  
  266.     The use of the AUTHINFO is optional. This command as documented
  267.     has a number of security implications. In the original and simple
  268.     forms, all passwords are passed in plaintext and could be
  269.     discovered by various forms of network or system surveillance.
  270.     The AUTHINFO GENERIC command has the potential for the same
  271.     problems if a mechanism is used that also passes cleartext
  272.     passwords. RFC 1731[8] discusses these issues in greater detail.
  273.  
  274. [...]
  275. This document expires December 1, 1996.
  276.  
  277.  ---- cut here ---- End of Barber: Common NNTP Extensions ----
  278.